

NASA-TM-86089 19840020466 

A Reproduced Copy 

OF 


AWss? 7-^- F 6J?? 


Reproduced for NASA 
by the 

NASA Scientific and Technical Information Facility 




FFNo 672 Aug 65 


LANGLEY RESEARCH CENTER 
LIBRARY, NASA 
HA*'?TQN, VIRGINIA 



H84-28535 


(NASA-Tfl-86089) C08S1DEB ATIOES 08 COfltJAUD 
AMD RESPONSE EAHGUAGB FEATURES FOB A METHQBK 
OF HETEROGENEOUS AUTOROHOUS COHPUTEBS (RASA) 

68 p UC A04/HP AO 1 CSCE 09B Unclas 

63/62 19631 



Technical Memorandum 86089 


CONSIDERATIONS ON 
COMMAND AND RESPONSE 
LANGUAGE FEATURES FOR 
A NETWORK OF 
HETEROGENEOUS 
AUTONOMOUS COMPUTERS 


Norman Engelberg 
Charles Shaw III 


JANUARY 31, 1984 



National Aeronautics and 
Space Administration 

Goddard Space Flight Center 

Greenpeit Maryland 20771 







CONSIDERATIONS CN COMMAND AND RESPONSE 
LANGUAGE FEATURES FOR A NETWORK OF 
HETEROGENEOUS AUTONOMOUS COMPUTERS 


January 31, 1 984 


Nornan Engelterg 
Charles Shaw III 


Century Computing, Incorporated 
8101 Sandy Spring Road 
Laurel, Maryland 20707 

for 

NASA Goddard Space Flight Center 
Contract NAS5-27197 



ACKNOWLEDGEMENTS 


The authors wish to thank the members of the TAE design and 
development team — Carmen Ana Eemanuelll, David Howell, and 
Dorothy Perkins of NASA Goddard Code 933! Elfrieda Harris 
of Science Applications Research; and Paul Butterfield, 
John McBeth, Philip Miller, Dharitri Misra, and Lora Mong of 
Century Computing, Incorporated— for their help in 
producing this document. 

The work for this paper was done under NASA contract 
NAS5-27197. 



ABSTRACT 


The authors consider the design of a unifora 
command language to be used In a local area 
network of heterogeneous, autonocous nodes. - 

After examining the major characteristics of such 
a network, and after considering the profile of a 
scientist using the computers on the net as an 
investigative aid, the authors derive a set of 
reasonable requirements for the command language. 

Taking into account the possible inefficiencies 
in icpleaenting a guest-layered net-ork operating 
system and conaand language on a heterogeneous 
net, the authors examine command language naaing, 
process/procedure invocation, parameter 
acquisition, help and response facilities, and 
other features found in single-node command 
languages, and conclude that soce features may 
extend siaply to the network case, others extend 
after sone restrictions are imposed, and still 
others require modifications. In addition, the 
authors note that soce requirements considered 
"reasonable"-- user accounting reports, for 
exanple — demand further study before they can be 
efficiently implemented on a network of the sort 
described. 
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1.0 INTRODUCTION 


With che Increased popularley of local area networks (LANs), 
we have seen che developnent of necworks of independently 
administered nodes, based on compucer systems from different 
vendors. Along with che development of these networks, a 
need has arisen for a uniform command language through which 
applications users may manipulate a sec of dispersed and 
independently managed resources. 

Ideally, the command language 13 simply some universally 
known command language available on all the nodes on che 
net. Work on such standardized languages — languages chat 
are Che same no matter che underlying cocroucer architecture 
or operating system-”is ongoing ([ANSI/Q9SD 84], [COSCL 
82]), but these languages are designed to provide a required 
set of functions; che committee charters do not permit 
significant considerations of possible implementation 
problems. (See [ANSI/05SD 79], [COSCL 82].) 

In this paper, we investigate one common networx case, a 
local area network with heterogeneous, autonomous nodes, in 
which the operating syscem che user sees — che "network 
operating system" — is layered on top of existing host 
operating systems, chat is, "gue3C-layered". (See [ROBINSON 
77], (MAMRAX 831, [PSS3LSS 80], and [LANTZ 82] for existing 
examples of such a case.) Thi3 paper examines classic 
command language features to determine how the command 
language might be extended to help the necvork user, and to 
determine how the nature of a necwork of heterogeneous, 
autonomous nodes might make che implementation of a given 
feature impractical. 

To perform this investigation we first examine che 
significant characteristics of a LAN with heterogeneous, 
autonomous nodes. Because we are investigating a user 
interface, we then describe the characteristics of che type 
of user for whom we are designing che interface and, based 
on che net and user characteristics, we propose a "user view 
model" (chat i3, che view of che system which we Intend the 
users to have). Using this user view and keeping in mind 
che necwork characteristics, we describe a sec of 
requirements on che command language. Finally, we present 
che features of a scrawman command language, discussing the 
viability of che features in terms of the difficulties each 
feature may presenc to che implementation of the layered 
support. As a basis for our discussion we use an exiscing, 
host-independent, single-node command language, "TCL", which 
the auchors helped design. 
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2.0 DEFINITIONS 

In order Co avoid some confusion in Che discussion of the 
issues, we first present a short list of our definitions for 
some common terms and acronyms. 

o node - a computer with memory and external devices 

o home node - the node on the network, onto which the 
user has formally logged on. 

o remote node - any node except the home node 

o local user - a user is local with respect to a node 
if the node is his home node 

o remote user - a user is remote with respect to a 
node if his home node is any other node 

o NOS - Necwork Operating System. The software 
provided to allow a user to access the resources of 
autonomous machines on a network. (See [FORSDICK 
78] for an alternate definition.) 

o NOSCL - Necwork Operating System Command Language, 
the object of chis paper 

o proc - a command procedure or an operating system 
process 

o TAE - The Transportable Applications Executive, a 
user interface and applications support executive 
in use at NASA's Goddard Space Flight Center. 

o TCL - The TAE Command Language, the reference 
language used in tnis paper; the cocaand language 
for TAE 
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3.0 


NETWORK CHARACTERISTICS 


P 


The type of network chac concerns us has 
significant characteristics: 


Che following 


o The reason for the existence of the network is to 
share resources among the users associated with the 
different administrative centers; chac is, the net 
is not primarily a testbed for distributed 
processing. 


o The network is composed of heterogeneous nodes. 
Unlike some interesting existing necs used for 
distributed computing ([POPEK 81], (JONES 79], 
[LAZOWSKA 81]), we can make no assumptions about 
uniformity of the underlying computer architectures 
or the host operating systems. The node may be a 
mainframe running OS/MVS, a sixteen bit 
minicomputer with a memory-resident operating 
system, or a microcompucer-based workstation. (We 
do not nece33arily include micros with arbitrarily 
small memories.) 


o It i3 a local area network. We assume that the 
data race between two nodes is on the order of 
between one and 10 megabits per second. (Note: 
there may be low-speed interfaces to ocher, 
possibly geographically distributed nodes; we do 
not want to exclude such an interface, but we will 
not drive the design of Che command language by 
them.) 


o The nodes on the network are under autonomous 
administrative control and the network operating 
system i3 guest-layered, chac is, it is layered on 
top of the existing host OS's. 

o The development of the capabilities of the net and 
the NOS are evolutionary; we want to be able to 
start with a set of basic capabilities and add to 
them as budgets permit and technology progresses. 

o The network is loosely coupled; we cannot assume 
that any two nodes share memory. 


The important implications we derive from these network 
characteristics are: 

o Because of the data races, we assume chac it may be 
reasonable to process records from a small file by 
copying the entire file from one node to another, 
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but It is noc reasonable to copy large files (not, 
for example, a sixty megabyte spacecraft image 
file). 

o A node owner may take down a node without 

consulting the network users or other node owners. 

o A node owner may change the configuration of 

peripherals on a node, changing the address of a 
tape drive, or removing a line princer, for 
example. 

o We can make no assumption about the existence or 
correctness of a user-readable clock. 

o Hot all users on a node will be users of the 

network operating system; a given node will 

support NOS users and users not concerned with the 
NOS or the network. Files may be generated outside 
the NOS, and accessed by both NOS and non-NOS 
users. 

o Most common devices (most line printers, for 
example) cannot be exclusively allocated to the 
NOS. 

o We cannot change the host OS to accommodate more 
comfortably the NOS or the NOSCL. 

o Because of differences in computer architectures, 
and because we want to be able ro run programs that 
may use host operating system services, we cannot 
assume that Che NOS can redistribute the 
application workload by moving an arbitrary process 
from one node to another. 

o Although we can assume chat the software providing 
the various levels of support for the NOS may be 
centrally developed, the only assumption we make 
about Che release level of the software at a given 
node is chat it is "compatible". 


See (ROBINSON 77], (FLETCHER 82], (PEE3LES 80], and [LANTZ 
80] for descriptions of nets that share most of these 
characteristics. 
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4.0 DESCRIPTION OF USERS 

Current wisdom (e.g., [SCHNEIDER 82], [SMITH 82]) dictates 
that when one designs a user interface, one should be aware 
of Che sort of task that the user is required to perform. 

The following is a fair description of one common type of 
computer user; it i3 also a rough profile of the intended 
user of Che TAE, the system for which the TCL command 
language was developed. 


o Someone with frequent need to use a computer as an 
aid in performing some analytical cask. 

o Not a computer neophyte. 

o Has the following basic requirement, based on a 
"function" model: 



output data 


responses 


The user has a task to do; the task transforms the 
inputs into some outputs. We add to this basic 
requirement a recognition that the user has to 
supply some parameters, and that there will be 
responses generated in the process of exercising 
the transform. Thus the primary user requirement 
is to specify Che location of the input daca, the 
transform to apply to the input daca, where to put 
Che output data, and the parameters used Co control 
the behavior of the transform. 

o Professional and cooperative, will not attempt 
malicious destruction of other users' resources. 

o Generally has a home base, that is, a computer most 
often used as the home node, but also has a need to 
log into any ocher arbitrary node. 

o Usually acquires and maintains files at Che home 
node, often by using a process outside of the NOS 
(a realtime data acquisition process, for example). 


5 



o Finally, although Che user's interface to standard 
software Is chrough the NOSCL, the user may be 
satisfied with local resources, that is, the user 
may not want to use or be exposed to the network. 


Two implications of che last characteristic are that a user 
on a node in the net should not suffer a degradation in 
apparent task performance as a result of che imposition of 
network software, and chat the addressing of local resources 
should be the same a3 in the single-node case. 


5.0 USER MODEL/USER VIEW 


A user-view model is the model Che user inevitably develops 
while using the system. Based on the apparent system 
characteristics and a level of abstraction chat is 
'comfortable to the user, it allows a user to predict what 
the system will do in a given situation. 

By forming a user model before the user interface is 
designed we present ourselves with a target against which we 
may judge our design. 

In this section we propose a user-view model of the network, 
based on the net and user characteristics described above. 
We assume the user corresponds to Che "intermediate" level 
of sophistication, described by Schneider in [SCHNEIDER 82). 
(See [HARDY 82] for why orienting a design coward the 
intermediate-level user is reasonable.) 


The user logs into a particular node using a host-dependent 
login sequence. From this node, Che user sees a collection 
of resources (processes, command procedures, files, devices) 
attached to autonomous computer facilities, each facility 
having a central computer and peripherals. The user 
manipulates these resources as necessary to perform a given 
task. The user can, for example, execute a proc on node '/I 
using a file on node if 2 as input, and depositing the cucput 
in a file on node if 3. 

The user executes commands through a single uniform command 
language, implemented in the NOS command interpreter. In 
addition, a user may invoke user-written processes or 
command procedures living on any machine on che net. The 
user specifies which node to use in executing a process or 
procedure (GODDARD/COPY, for example). 

A user may access files on any node in the net (given 
appropriate permission) by specifying the node name and the 
r m. of the file on that node. Devices on the net may be 

a. essed by specifying the node name and che device, or 

generically, by specifying a suitable device type. 

The user view is node-centered, that is, the user is 
registered as a user on a given node; if the user wants to 
establish a session by logging into another node, the user 
must be registered on that node (or use a guest account). 

Most command error messages are nachine-independenc ; some 
error messages have a machine-independent description with 
machine-dependent details. 
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This view concrascs with the view implemented on ocher 
systems in which the user need never be aware of the 
location of resources (e.g., [ROBIHSON 771, [LAUTZ 82], 
(FLETCHER 82]). In Che proposed view, the user must know on 
which node files are located, is occasionally exposed to 
possibly confusing error message details, and receives a 
different view of the available resources depending on the 
node which is used as the home node. 

We justify this view as follows: 

o If the user knows that a node is about to go down 
(for example, for scheduled maintenance) the user 
may transfer files to another node. 

o If the user knows that a node has gone down, the 
u3er may conclude something about additional files, 
devices, command procedures, and processes. 

o As noted by 'Clark and Svobodova (CLARK 80] an 
implication of autonomy is that a user cends to use 
one machine and wants the access to that user's 
data to be most efficient from that machine. 

o The user may configure his files such that 
important files are backed up on physically 
independent nodes. 

o The user may want to control and display the costs 
of working on a network. For example, the use of a 
data file on the user's local node is apt to be 
cheaper than the use of a file with the same 

contents on a remote node; the cost of using 
functionally identical application processes on 
different nodes will differ according to whether or 
not the required data files are on the same node as 
the process, and on the speed and billing 

algorithms for that node. 

o The user may wi jh to communicate with the remote 
operator; for tape mounts, for example, or for 
complaints, and information about computer 

downtime. 

o If a user's files are not replicated, file access 
times will vary according to the hosting node; the 
user may want to plan file usage based on ease of 
access to some files. 

o Some operations will not be available between two 
arbitrary nodes. For example, it may not be 

possible, in initial implementations of the 
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network, for a user on a PDP-11 to access a file on 
an I3M machine. 

o A user may need to perform more complicated 
recovery and detection if an error is due to a 
remote problem. If the user knows that the 
reference is local, then these procedures are not 
necessary. (This was cited by Clark and Svobodova 
[CLAKK 80] for application programs, in which the 
program would have to provide logic for the core 
complex case if it didn't know that the reference 
was local.) 

o Errors may occur as a result of the inability of 
the NOS designers to perfectly map the network OS 
onto the host OS, exceeding a quota or violating a 
privilege, for example. Although the NOS can map 
these errors into NOSCL errors, the user may need 
to know the host error code in order to correct the 
situation. 

o The user may want to be sure that secure 
information 13 placed on a specific node. 

o Although it is possible to design a user interface 
chat has apparent network transparency, the user 
inevitably becomes aware of and rust deal with che 
network. Assuming a user interface designed to 
make the network transparent, factors that support 
this assertion are: 

- The user will notice that file access tines 
vary considerably according to the file being 
accessed. 

- Because of node autonomy and the varying 
reliability of node hardware, resources 
attached to seme nodes will be generally less 
available chan resources attached to others. 

- The user will note operating system-dependent 
terminal characteristics, for example che 
ability to type ahead when addressing some 
processes but noc others (from VAX/VMS to 
VAX/VMS but not from PDP-ll/RSX to PDP-ll/RSX, 
for example). 

- Error messages from application software will 
display host-dependent error codes. 
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Users on one node will cotaamicate with users 
on another node. 


Note that sone of the itens deed above reflecc what we 
believe are the inadequacies of current software technology 
to provide these functions efficiently in a network 
operating systen. In particular, copying arbitrary files 
froa one node to another, user cost minimization in a 
heterogeneous node environment, optimizations for relative 
location of files and processes, and automatic recovery, are 
not now available in systems with heterogeneous nodes and 
guest layering. 

Other nets that preserve a view of node visibility are 
COCANET [ROWE 82] and UNIX-UNITED [3R0WNBRIDGE 82], 



6.0 REQUIREMENTS 

la this section, we present a list of reasonable 

requirenents for a command language designed to support cne 
network and user view we have described. We list only those 
requirements of interest in the network case; for a more 
extensive set of command language requirements, see 
[ANSI/05SD 79] and [ANSI/06SD 79] . Note also that some of 
hese requirements are more properW requirements on a 
network operating system; they do, however, affect the 
command language design. Finally, although we conside” 
these requirements reasonable from a user's view, we note in 
Section 7 that some of these requirements present 

difficulties in efficie.i- implementation. 

1. Related to files and other resources . 

. - support for uniform file specifications and 

device specifications independent of the 
underlying host operating system, with at least 
one level of directory 

- file management commands: make a copy of a 

file (i.e., COPY), rename a file, list a text 
file, list a directory, delete a file 

- manipulation of a file using wild cards for a 
name component 

- location of a file by attributes other than the 
name (a file "type", for example) 

- logical names: the ability to map a 

user-defined name into an existing object name 
or another logical name 

- on protection: consistent user view of 

protection for all files accessible through NOS 
file specifications; basic read/write/delete 
protections at least by "owner" and non-owner; 
ability to protect files from aon-NOS users, 
and to share read access to files with non-NOS 
users; ability to set and determine protection 
of a specified file 

- ability to specify a host file in host 
specification format 
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2. Relaced Co handling of processes and command 

procedures 

- named packages of commands (procedures), with 

parameters and language support (loops, 

conditionals, variables) 

- process/procedure status query 

- specifying a host node to use in executing a 
transform 

- ability to initiate concurrent processes and 
procedures 

- procedure/process abort, suspend 

- automatic action upon a specified type of error 
(that is, some basic exception handling) 

- ability to run programs that have not been 
designed to interface with the ROS 

3. Crash/recovery 

~ notification of crash of any node with which 
the user is communicating 

- restoration of files to a known state (e. 3 ., 
previous version or "locked" or "recovered") 

- survival of the user/ROS interface following a 
crash of any node except the user's home node 

For dealing with machine costs: 

- a way to determine the costs (storage and time) 
of having invoked a process or procedure 

- query for cumulative machine costs since login 

5. For sharing ocher users' resources and 
communication with ocher users: 

- the ability to locate and access other users' 
files 


[] 
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- file/device protection 

- query for file ownership 

- determine id's of other users currently logged 
onto the network (under the NOS) 

- send/receive messages and mail 


Requirements related to visibility of the nodes and 
the network 

- the ability to log on to a remote host from the 
home node 

- query for the network status 

- query for status of one or more nodes in the 
network 

- ability to comsainicate with a remote ho3t 
operator (for example, mount a tape, or receive 
a message on host downtime) 

- downloading a remote host 


Help and error handling/status reporting 

- notification of errors using a uniform, 

host-independent message structure 

- determination of error details and possible 
recovery actions including ability to get help 
on an underlying host-dependent error 
originating at a remoce node 

- help displays on processes and command 
procedures, built-in commands, general 
how-to-work the system 

- help on characteristics of the network (to the 
depth required to support the user view) and on 
network problems 

- help on host-host incompatibilities (in general 
help Inquiries and error messages, e.g., "Image 
file copy from PDP-1 1/RSX-l 1M to WANG VS20C0 is 
not currently supported") 



8. General user-oriented requirements 

- If a user specifies an operation requiring only 

local resources it should not be more difficult 
to perform or take a perceptibly longer time 
chan che sane operation in a non-network 

environment 

- Some consistent time base and consistent 

user-view of time, that is, the user's 

perception of che passage of tine based on time 
displays from the system should be consistent 

no matter che node, and che use of time in 

time-related attributes for resources ("time of 
creation" for example) should be consistent. 

- Host command escape (the ability to execute a 

command in Che command language of che 

underlying ho3C operating system), local host 
and specified remoce host 

- ’'Reasonable" and consistent response tines 

where by "reasonable" we mean a response time 
comfortable for che user; see pages 228 

through 232 in [SHNEIDERMAN 80] for a 

discussion on user psychology and response 
times. 
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7.0 NETWORK COMMAND LANGUAGE ISSUES 



la this section we briefly describe our reference command 
language, TCL, and present our basic model for the network 
operating system. Then, using TCL as a reference language, 
we discuss the classic characteristics of command languages 
and how they might be affected by the requirements we've 
developed. 


i 
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7.1 Description of TCL 

As a basis for the following discussions on network-oriented 
extensions to command languages, this section describes TCL, 
a modern command language designed for a single-computer 
system. 

The following overview is a description of the facilities of 
TCL pertinent to the NOSCL issues discussed below; a 
complete description of TCL can be found in [CENTURY 83a] 
and [CENTURY 83b]. 


The major purpose of TCL is to provide a language through 
which users of the Transportable Applications Executive 
("TAE") may invoke and provide parameters to scientific 
analysis software. 

In TCL, an application program linked to run under the host 
operating system is called a "process"; a file consisting 
of a sequence of TCL commands is a "procedure". 

A command in TCL is a TCL intrinsic command, or the 
invocation of a TCL "proc". A proc is a procedure or a 
process; all procs are located in TAE libraries 
(corresponding, under VAX/VMS (DIGITAL 82a], to a file 
directory). 

Intrinsic commands are commands built into the TCL 
interpreter (the TAE Monitor). These commands consist of 
commands that perform general utility functions ("DISPLAY" 
to display the value of a variable, for example), and 
language-support commands such a3 the IF and LOOP commands. 

In TCL, a proc is invoked using only the proc name; there 
is no "RUN" or "EXECUTE" command. The proc definition 
file — the file containing the procedure or executable linked 
image and the proc parameter declarations — is located by the 
command line interpreter using an ordered search of TCL 
libraries (similar to the path search in UNIX). The list of 
libraries to search is established by the TCL user during 
the session. Libraries are mapped directly into the host 
file facilities; under VMS, for example, a library 
corresponds to a directory. Intrinsic commands pre-empt 
procs; chat is, if a command name is found to be the name 
of an intrinsic co mma nd , then no proc search is done. 
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A command Is said to have "proc invocation syntax" if the 
fora of the command invocation is, 

<command name> parameter value list> 

A process receives command line parameters by calling 
standardized TAE support subroutines; a procedure receives 
Che parameters by declaring them as parameters in the 
procedure. 

TCL also supports the following traditional features: 

o typed variables, arithmetic and logical 
expressions, built-in functions, and a LET command 
for assignment; 

o IF, LOOP, BREAK, and GOTO commands; 
o exception handling support; 
o on-line help and message facilities 
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7.2 Network Operating System Model 

la order to provide a basis for discussing the possible 
problems in implementing the various command language 
features, in this section we describe the basic model we use 
for the network operating system. The model we have chosen 
Is appropriate for our user-view model; it is based partly 
on the single-node TAE model [CENTURY 83a] and partly on the 
service model in [FLETCHER 80] and the implementation of 
DIGITAL's DECnet [DIGITAL 82b]. The discussion is limited 
to those aspects of the NOS that clearly affect the command 
language interface. 

We suppose a network of nodes, where every node contains the 
necessary hardware and software communication support for 
layers through the session layer of the OSI reference model 
[IS0/0SI 82]. Each node hosts, in addition, an executive, a 
directory server, a file server, and a "listener”. The 
executive interfaces with the user; it interprets the 
user's commands, determines the command parameter values, 
and passes the parameter values to the responsible execution 
module. It also determines the status of the command 
execution and forms appropriate status responses for the 
user. 

A user is "registered" on each node through a user node 
registry. If local access is desired, the user's name alone 
is registered (e.g., "JOHN"); if remote access is desired 
then the node from which the access is attempted and the 
name are registered (e.g., "NASA/ JOHN") . (This approach is 
similar to the UNIX-UNITED approach [BROWNB RIDGE 82].) 

A command module may be built into the executive command, or 
it may be a command procedure contained in a procedure file, 
or it may be a process (a program in host-dependent 
"executable" format on disk). If it is a procedure or a 
process (a "proc"), there is an associated proc definition 
file that the executive accesses to determine the type, 
default value, and ocher attributes of the parameters. If a 
parameter has no default and no value is specified by the 
user, the executive will prompt the user for a value. The 
proc definition file may, depending on the implementation, 
be incorporated into the procedure or executable program. 

The executive uses the directory server to determine the 
location of files. Because nodes in our user model are 
exposed to Che user, there is one directory server per node, 
and it knows only about the files and devices located on the 
hosting node. The executive or subroutines in an 
application program direct the file request to che correct 
node by finding the node name in the file specification (or 
using a default node name). 
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In general, files are not copied from one node to another 
unless the user explicitly requests so; processes read and 
write local and remote file records. 

When a request is made to open a file, the request is sent 
to the directory server on the appropriate node; the server 
returns to the requester a file identification string or a 
"not found" status, or an "access violation" status. The 
possessor of the file identification string, the executive 
for example, then uses the file server to access the file. 
If the request is for a file on the same node as the 
requester then the file server may be embodied in a 
combination of host OS file services and the subroutines 
required to abstract them. If the request is for a file on 
a node remote to the requester, then the requester 
communicates with the remote directory server (through the 
listener, see below), and a remote file server uses the host 
OS facilities to perform the necessary file access services. 
(In practice, the directory server and the file server may 
be combined in one process.) 

The file identification string provides sufficient 
information for the file server to check access rights 
against the requested operation (similar to capabilities 
[DAVIES 81]). 

The listener on each node is responsible for the initial 
interface with ocher nodes. When a file open is requested 
by a user remote to the listener's node, the listener either 
spawns a directory server or communicates with an existing 
directory server, which thereupon establishes communication 
with the requesting process. 

If the request is for the execution of a remote procedure or 
process, the liscener spawns a local copy of the executive. 
The spawned executive communicates with the originating 
executive, obtaining the necessary context for the requested 
operation, and executing the process or procedure. 
Furthermore, if the proc is a procedure, the executive is 
responsible for executing che commands in the procedure. 
For a discussion of ocher functions and problems wich this 
remoce execution model, see "Proc Invocation" below. 

A remoce proc communicates with Che user through subroutines 
in Che process, which communicate with Che proc's executive, 
which, in turn, communicates with the user's home executive. 
The user's home executive talks to Che user (similar to 
virtual terminals; See [LAJ1TZ 79] for a discussion on 
virtual terminals.) 



Note that, for simplicity, our model does not at this stage 
provide for replication of any user files; we leave file 
replication to the user. In addition, the model does not 
address protection of objects; we leave the investigation 
of a protection model appropriate for our user model, and 
the associated impact on the command language, for future 
study. (See [DAVIES 81] for a general discussion.) 
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7.3 Command Language Features 


This section discusses the important features of a strawaan 
command language we call NOSCL; most of the features 
discussed relate to a requirement listed in the 
"Requirements" section, above; some of the features are 
based on existing features in TCL. Note that, where 
necessary, we assume the command line syntax of TCL [CENTURY 
83a]. 

The descriptive technique we use below is to first describe 
a hypothetical NOSCL feature, then discuss the feature. 


1. Session context 

When a user logs onto the NOS, a "session" is started 
and a session context is established. 

In NOSCL, the concext consists of: 

o user name 

o session id - a unique identifier for the duration of 
the current session 

o a string that constitutes the command line prompt 

o a sec of logical name3 that map into file names (see 
"Names" below) 

o "current" directory - the default directory string 
to be used if an object name is not fully-qualified 

o "hone" directory - che initial "current" directory 
upon login 

o current setting of session global variables 

o proc search list - the list of directories to search 
for a proc invoked with an unqualified proc name 

o a sec of user and installation-defined commands 
command string equivalences and abbreviations 
defined using the "define equivalent command string" 
command 

o devices reserved 
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o Che user's NOS identification 

o identification of all procs currently executing 
o name of log file and state of session logging 


The context is available to the NOSCL user through a set 
of global variables; to display a context component, a 
user may use the standard NOSCL command for displaying 
variables, or for 3ome frequently requested components, 
the SHOW command (e.g., for showing the library search 
order). 

There exist commands to save context to a named file, 
and to restore context from a named file. 


Comments 


We try to keep the context as small as possible for two 
reasons. First, the context will require memory in the 
executive (or from some memory pool), and, second, in 
our model of the NOS, when a proc on a remote node is 
executed, the home executive sends the entire context to 
the remote executive. 

Note that the second consideration may turn out to be 
unimportant, depending on where the bottleneck for 
remote proc initiation is, on the effective rate of data 
transmission between two application-level processes in 
the network, and on the efficiency of the data encoding. 
(Binary data, for example, may have to be encoded as 
ASCII characters.) We estimate, based on experience with 
TCL (which does not have logical names), that the 
session context as defined above may be as large as 10 
kilobytes. Note also that some optimizations are 
possible; for example, once the home executive has sent 
the context to the remote executive, it may, on 
subsequent proc invocations on that node, send only 
changed portions of the context. 

Session quotas, accounting information, and session 
privileges are important components of the session 
context on an operational system, but hard to define and 
implement in a distributed environment. We have omitted 
them pending more study on the necessary NOS structures. 

In addition, the context may include the current 
position of a magnetic tape, but it is not clear chat 
this would be meaningful for the user to observe, nor 
can it be easily restored in a new session. 
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The current time and date may also be considered part of 
the session context, because It qualifies the rest of 
the context. See "Tine” below for further discussion on 
this coaponent. 


2. Login 

NOSCL users are required to login to a host, using the 
appropriate host-dependent login sequence; host 
facilities are then used to automatically log the user 
into the NOS (using VMS's LOGIN. COM, for example). In 
addition, a user may establish another session on the 
sane node or a rcaote node using the NOSCL LOGIN 
command, a standard host Independent login. In that 
case, the user sust be registered as an NOS user on the 
remote node. 

Opon initiating a NOSCL session, a special login NOSCL 
command file (called the "node login" file) in a 
reserved NOS directory on the hone node is executed, 
which, in turn, executes a login command file in the 
user's default directory. There is one node login file 
per node. 

A user is registered wich the NOS in an NOS user 
registry (using a utility not specified here). The 
registry specifies the user's NOS identif icatlon, and 
initial defaults (the initial default directory for 
example). The login process accesses the registry for a 
particular user by that user's login name and, for a 
remote login, by the user's node name. 


Comments 


Further investigation is required for a complete 
specification of the data structures in the registry. 

The login process establishes the Initial user context 
using the NOS registry and the login command files. The 
technique wherein the system and user login command 
files are Invoked is currently used in TCL. The user 
login command file together with the registry records 
for a user constitute the user's profile. 

Note that a user that establishes a session on node A 
appears to the NOS as a different user than the same 
user establishing a session on node 3; the user login 
file that is executed is dependent on the node. User 
login names are not unique for the entire network, but a 
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login name Is required Co be unique for a given node. 
This approach ha3 che disadvantage chac, depending on 
how protections are implemented, a user may not be able 
to access files he created while logged onto another 
node. (If the registry is logically unique, the NOS may 
. be able to cap the user node and name into a unique 
protection token, thereby avoiding the problem.) 

Although the location of the registry is not specified, 
we establish the requirement chat the information 
necessary for establishing a session on a given node is 
resident on that node. This requirement is derived from 
the requirement that the performance for a user using 
the NOS executive but not che network exist not be 
significantly affected by Che existence of the network. 
See [BIRRELL 82] for more on user registries. 

Note that the facility to login on one node and start a 
session on another host i3 extremely useful; it means 
that if the user knows the host-dependent login sequence 
of Che local node, that user can start a session on 
another node without knowing che host-dependent login 
sequence for chat node. 

Finally, wa note that, in a macure operating syscem, che 
registry would certainly include the user's privileges 
and session quotas; it is not clear however, what che 
list of privileges should be on an NOS, nor do we yet 
understand hew to handle quoca3 in a distributed system. 


3. Names 

In NOSCL, an object with a standard name is named by its 
node and by a path-name within a node. A 
fully-qualified name i3 of Che form, 

<node-name>^<directory>/. . ./<directory>/<simple-name> 

If a name starts with "tf", or then che object is to 
be found on che local node, and the first directory 
after the or "/" is che user's home directory. If 
Che name doe3 not start with a node name or a or 
"/", then the current default directory string i3 
assumed to precede the specified name. The first 
directory name in the string is the name of a user if 
the node has more than one U3er. 
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If che name is preceded by a co-bc-de3ignaced special 
character, che naae is taken as a nane in hose OS format 
on the home node; if the special character appears 
after Che node marker, the nane is taken to be a node 
nane and che 3Cring following Che special character is 
to be interpreted as a host file specification on che 
designated node. Host names oast be enclosed in 
quotation narks if they contain any of the NOSCL special 
characters.* 

The naxinun length of a node-name, directory nane, or 
simple-name is the sane for all nodes, as is che naxinun 
depth of the hierarchy. 

The objects that have standard names are directories, 
devices, files, users, processes, and command 
procedures. 


The fully-qualified nane of a device on a given node is, 
<node-nace>'?DEVICE/<device-name> 


For example, 

N10DEVICE/LP1O 

The <device-nane> for a given device is established by 
the system administrator for chac node; conventions 
will be established for uniform naming by device type. 

For all objects with standard names, except processes 
and procedures, if an object's nane is noc fully 
qualified, the nane is formed by placing the current 
default directory string in front of Che name specified. 

For processes and procedures, there exists a search 
list; search lists are described belcw, under "Proc 
Invocation". 

In addition to the name3 described above, a user may 
define a logical name. A logical name Is a nane that is 
defined to map into an object name or into anocher 
logical name. For example, a user may define TESTFILE 


* A special character is any character having significance 
to the command line interpreter. 
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Co map inco /NHE/TESTDIR/TESTFILE, or LP co nap into 
Nli?DEVICE/LP10. There la one logical name directory per 
user, with initial entries typically set by the node and 
user login command files. 


Comments 


The fully-qualified name specification described above 
was chosen because it conforms with the proposed 
user-view model and because it is compatible with the 
latest specification issued by the ISO SC16 committee. 
[IS0/SC16/N1454 83] Note that, by having both the two 
distinct separators {"if" and "/" in our case), we allow 
a form of fully qualified name whereby the node name 
defaults to Che local node. See [FLETCHER 82], 
[ROBINSON 77], and [LANTZ 80] for nets with 
heterogeneous computers and no node name in the file 
spec. 

A possible extension to the name specification used by 
the ANSI committee is to provide for hierarchy of net 
names, N1/N2/N3./J0HN/AFILS, for example. (See 
[ANSI/09SD 84].) 


Names for variables, exception handlers, and labels are 
not considered standard names as defined above. The 
names for chese objects will depend on the procedure 
language; in TCL, they are simple names only. 

Currently under investigation by the ANSI T3H1 committee 
is whether or not any object attributes — the VMS file 
"type" and version number, for example — should be part 
of the name. We will wait for further results from the 
committee. 

A relaced question is whether or noc to support access 
by object attribute when the attribute 13 not part of 
the name. (It may be another parameter in the command, 
for example.) This technique is particularly useful if 
device type is an attribute; a service can be defined 
to return the names of all objects with the device type 
attribute set to a specified string, "line printer", for 
example. Further progress on chese issues will follow 
investigation into what attributes should be supported. 
We note, however, that search-by-3tcribuce is an 
expensive mechanism even on one-node systems (generally 
requiring a separate sec of pointers). 


The technique for naming devices is taken from UNIXtm 
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[BELL 79], and has the disadvantage that It reserves a 
directory name. It is expected that installations will 
define logical names for all devices. 

An aJcemace technique to be studied is allowing the 
device to take on any name in any directory and defining 
an attribute, as noted above, that indicates an object 
that is a device of a specified type [AGRAWALA 83] . 
Thi3 would allow a systea manager to name the "device" 
directory by any name; a user would reference a device 
through a logical name or by requesting an object with 
the specified attribute. 

The restriction that the maximum depth for directories 
is the same for all nodes is made for user-friendliness, 
but may use too much processor memory for nodes with 
little memory to spare. (The maximum depth of 
directories i3 an important number in determining memory 
use by the executive, since it determines the space 
allocated for file type parameters and variables, and 
for logical names.) For ease of implementation and 
portability, consideration should be given to limiting 
the depth of the directories to some fixed known value, 
as in GRAPEVINE (BIRRELL 82], and Clearinghouse [OPPEN 
83]. 


Logical names provide for node name transparency, 
particularly useful for device names, aliases, and 
"standard" devices (standard output device, standard 
error device, etc.) 

There are no logical names automatically known across 
the network, thac is, no network-central directory of 
logical names; system administrators coordinate the 
node login command files to define common logical names 
for devices and files used by many users. (The 
assumption here is that the logical names used across 
the network, names that cap into devices for example, 
change infrequently.) We have avoided centralized 
directories for logical names because they imply either 
a remote access to the central directory every time a 
name is referenced, or replicated directories. We have 
provided Instead a primitive form of replication, thac 
is, system administrators updating the node login files 
through an editor. 

For flexibility, logical naaes 3re bound to the physical 
name when the name is used, and not before. Some of Che 
tradeoffs on logical name binding, on network-wide 
logical names, and on directory replication are 
discussed in the GRAPEVINE and Clearinghouse papers 
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deed above; Wacson also discusses binding in [WATSON 
81]. 

Open questions related to logical names are: 

- Can a logical name map into a node name? 

- Can it map into a node name plus the left part of a 
file name? (Consider LNtfA.B where LN is defined to 
map into NIK.) 

” Should logical names be restricted to the left side 
of a name specification (as in VAX/VMS) or can any 
component of a name specification be a logical name? 

“ Should logical names have attributes? If the design 
is 3uch that the user cannot tell a logical name 
from an object name, then logical names should have 
attributes. (This capability is useful when 
searching by attribute: the search would yield a 

list of object names and logical names.) 


An iS3ue not discussed above is in what contexts wild 
cards should be permitted. Clearly, on a network, a 
wild card in the wrong place can produce disastrous 
consequences. 

Finally, we note that our syntax for host file names may 
result in awkward file specifications such as: 

Hl«"[l,l]*.y" 

assuming the percent character marks a host file 
specification. 


A. Proc invocation 

Process and command procedures are invoked by naming the 
proc and providing the values of its parameters. For 
example: 

PR0CP1 1, 2, 3 


If Che name of the proc is the fully-qualified name of 
Che proc definition file then the proc definition file 
in the specified directory is used; otherwise the 
following proc search algorithm is used. 
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If the executive determines that a command is not an 
executive built-in command, the executive assumes that 
the command is implemented as a process or procedure. 
It then searches in the following directories, in order: 

1. the user's current default directory 

2. the directories in the search list established by 
the SETSEARCH command 

3. a directory designated as the "system" directory on 
the local node 


A search list cannot include a directory on a remote 
node; to invoke a proc on a remote node a user oast 
fully qualify the proc specification, including the node 
name. Furthermore, if the currently executing proc is a 
procedure on a node remote to the user's home node, then 
the search list is automatically restricted to the 
user's current default directory, the directory of the 
remote procedure, and the system directory; that is, 
the variable part of the search list is reduced to the 
directory of the remote proc only. 


If the user does not specify all the required parameters 
for a given proc, the user is prompted for the missing 
parameters. A parameter chat has a default defined is 
not considered a required parameter. 


Comments 


The basic proc invocation syntax is, from the user's 
view-point, a common one. It is currently in use in 
TCL, and is similar to that being used in COSCL [COSCL 
82] and in ANSI X3H1 discussions [ANSI/09SD 34 ]. The 
notion of prompting for user parameters is available in 
TCL, buc the "tutor" mechanism is preferred. (See the 
TAE User's Manual [CENTURY 83a] and Programmer's Manual 
[CENTURY 83b] for details on this and on the 
specification of parameters on a proc invocation line.) 

There are some problems with implementation of this 
simple model on a network of the type chat concerns us. 

In TCL, there exists for every process and procedure a 
definition file. (For a process it is in a text file 
distinct from the process; for procedures, it is 
located at Che start of the text-fo enacted procedure.) 
The proc definition contains parameter descriptions, 
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necessary for parameter value checking and for parameter 
prompting; a description includes the type of 
parameter, the parameter default value, and, possibly a 
list of valid values. 

Given these parameter descriptions, we have the problem 
of how to efficiently prompt the user for parameters 
when the proc is located on a remote node. Using our 
NOS model, if a proc is on a remote node, an executive 
on the remote node handles the command line processing. 
If the remote executive does the prompting, we have a 
relatively slow interactive dialogue; if the local 
executive does the prompting then it must access a 
remote file (and probably copy at least the parameter 
description portion), thereby forcing a lengthy proc 
initiation time. Another approach is for the parameter 
descriptions to be located on all nodes that access the 
proc; this approach would probably be faster (it still 
requires both executives to open a file, but no remote 
access), but it presents a proc maintenance problem: 
the person responsible for the proc tnisc remember to 
check for all duplicates of the file when updating it. 

Listed below are some additional problems in regard to 
proc invocation: 

- In the current TCL, the author of a proc can specify 

that a parameter is an "input file", that is, the 
executive is to check that the file exists. This 
implies the file mist be opened twice: once by the 

executive, once by the proc. Should this capability 
be retained given that the open may require several 
remote file accesses through the NOS file system 
(which is layered on type of the host system)? 

An argument in favor of early checking for file 
existence is that it may be expensive to run the 
proc on a remote node, and then to discover during 
proc execution that the file doesn't exist. 

Note that it possible to generalize the early-check 
capability to all devices, that is, we can specify 
that a proc will not run unless all devices 
specified in the parameter description set are 
available. We prefer to let device availability be 
tested when the device is required. 

- Because there will be configuration differences 
between copies of the executive on different nodes, 
a user might find that some proc invocations are 
acceptable on some nodes but noc others. Thu3, for 
example, a user may specify a long string value for 
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a parameter and tho string may be rejected (because 
the maximum string length on one node may be 
different than on his home node). This problem can 
be solved by declaring that there are no differences 
between executives, but such a solution is 
unsatisfactory when the range of processor memory 
size and disk space on the net is great. 

(The entities that are parameterized in the current 
TCL executive include number of parameters allowed 
on a line; number of command line continuations; 
ho3t filespec length; maximum length of message 
key; maximum allowed 17 nesting in a procedure; 
maximum depth of proc nesting; maximum number of 
characters in a string parameter; and maximum 
number of values for a vector parameter.) 

If a user has defined a number of new command 
strings (defined "COPYING" to mean "COPT HiAGEFILE" , 
for example), we have the following problem: a 
procedure is developed on node N using the command 
strings defined by both the system manager (in the 
node login file) and the proc developer; the 
context of the execution, however, contains only the 
command strings defined by the user and user's 
system manager. (For example, the procedure may 
assume COPYING is defined, but no such definition 
exists on the home node.) Using NICOLA /KIWINET's 
"abstract machine" concept ([EFE 83], [KUGLEK. 80]) 
we can say that a procedure is developed to run on a 
certain abstract machine, and chat our model does 
not provide that machine. 

If NOSCL supports floating point parameters (as TCL 
does), then a problem seen on nets with 
heterogeneous nodes is that it is impossible for a 
parameter to maintain tne same precision among 
different hosts. The precision in a user-supplied 
floating point number may be lost when convert j to 
the node that hosts the proc; a proc that does 
nothing at all except return the input value, may, 
in effect, change the value. See [KIMBLETON 81] for 
more discussion on data transfer between different 
hosts. 


In regard to proc search lists, we do not permit search 
lists to reference remote nodes because we believe that 
Che increase in the maximum search time (incurred on 
mis-cyped proc names) would be unacceptable to the user, 
and because the co3t associated with the execution of a 
remote proc nay be significantly greater than chat for a 
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local proc. Thus we force the user to specify the 
name (or map to it using a logical name). 

For procedures executing on a remote node, we set the 
variable part of the search list to the remote 
procedure's directory only, because the complete search 
list as seen by the user on his home node refers 
exclusively to directories on the home node, a node by 
definition remote to the node executing the procedure. 
Thus, if this restriction 13 not imposed, a proc search 
from a remote node would use only remote accesses. The 
remote procedure's directory is placed in the search 
li3t because access of this directory is local, and 
because proc packages often consist of several procs in 
one directory. 

Note also that search lists on single-computer systems 
have been criticized [3EECH 80] as being unkind to the 
u3er in that a user may find that a command defined in 
one way one day is defined differently (that is, with 
another proc) another day or on another system. If 
these lists are made to span autonomous systems, which 
may use different naming conventions, the definition of 
a given command is still more unpredictable. 


Two significant problems relate to the invocation of 
programs that were not designed with the NOS in mind. 
The first problem is that the program's parameter 
interface will not match the NOSCD interface; thac is, 
the programs do not use the standard NOS "get parameter" 
routines. Assuming the program gets its inputs from a 
command line, approaches to this problem are: 

- create a host-privileged program that captures the 
parameters in NOS-standard fashion and uses host 
operating system services to form the proper 
host-dependent inputs; 

- translate the NOSCL command line into a command line 
acceptable to the host; 

- provide, on each host, a procedure thac performs the 
mapping 

See [BRADEN 80], [LANTZ 80], and [KIMBLETON 78] for more 
discussion on this problem. 

The second problem is that there will exist on several 
nodes on the net some utilities — a FORTRAN compiler, for 
example — thac perform identical functions but which 
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provide different options depending on the host 
operating system. The FORTRAN compiler on some — but noc 
all — machines may provide a "debug" option, for example. 
Possible approaches are to define the NOSCL interface 
such thac it provides all possible options; define the 
NOSCL such thac ic provides a useful subset; let the 
host machine provide a NOSCL procedure for each such 
utility to present the options relevant to chat host; 
or to call it a host-dependent issue, and just let the 
users use a host escaping mechanism. Because no changes 
to Che command language are required, we favor the 
procedure approach. See (SCHICXER 75] and [KIMBLETON 
78] for more discussion on this issue; see also the 
standardized command language efforts ([COSCL 82], 
[ANSI/09SD 84]) which mist confront this problem as 
well. 


5. Protection 

To perform an operation on a file (make a copy of it, 
for example), a user must have "appropriate" access 
rights. 

The "create file" command provides the user with the 
capability to set the file protection, explicitly, or by 
default. 

There are commands to change the protection of a file 
and display the protection of a file. 


Comments 


While noting chat protection is more in the domain of 
NOS study than NOS command language study, and also 
noting chat the business of mapping protections for a 
guest layered file system into a host system is an 
enormously complex topic, we nevertheless outline the 
characteristics chat we believe appropriate for the 
proposed user-view model and requirements: 

o The protections we refer to here are associated with 
files named using the NOS file system, noc Che host 
file system (although we assume chat the NOS file 
3y3tem is layered on the host file system). 

o We consider files and directories only; the system 
may or may noc extend to ocher objects; at the user 
level it is noc now clear what ocher objects need to 
be protected. (Devices here are considered files.) 
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o The basic requirement is for a simple system; a 
highly secure system (one that implies data 
encryption, for example) is not required. 

p The basic protections required are: 

- Some users will have read, write, and delete 
access to a given file, according to the class 
of user, as described below. 

- Some users will have no access whatever to a ' 
given file. 

- The "owner" is defined to always have all access 
rights (read, write, delete). 

- The owner of a file must be able to protect 
files from the class of users consisting of all 


users remote 
exists. 

to the 

node on 

which 

the 

file 

- A user must 

be able 

to protect 

files 

from 

the 


class of users consisting of non-NOS users, and 
must have the ability to share read access with 
non-NOS users. 

A user oust have the usual necessary access 
rights to directories to craverse a path ending 
in a file. (To delete a file, for example, one 
must have "write" access to the directory.) 


o A final requirement: the protection system must not 

make file accesses unreasonably slow. 


See [I7IP/WG2.7 1983] for a protection model relating to 
command languages. 


6. Device management 

The RESERVE command grants the user exclusive access to 
a specified device; the RELEASE command releases it. 

The RESERVE request is not queued; if the device is 
reserved by another user, the request is denied. 

There is also a command to show the status of a 
specified device. Because all devices are seen as files 
attached to the DEVICES directory on each node, the 
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scacus of all devices on a given node can be displayed 
using a wild card with che sane "show scacus" command 
used for a single device. 

A possible scacus for a device, added for che network 
case, is "device noe available Co non-local users." 


ComnenC3 


NoCe chac we use exclusive reservacion for siaplicicy. 
More refined levels are of course possible; for 
example, reservacion such chac che user is only 
guaranceed chac no ocher user will wrice co che device. 

The following quescions remain co be invescigaced in 
regard Co device reservacion: 

o Is ic possible for a user co reserve a device chac 

Is accessible Co non-NOS users? Assume we have an 

NOS process on each node called che ALLOCATOR, which 
concrols allocacion of Che device among NOS 
processes. If che device is shared wlch non-NOS 
users on a node, ALLOCATOR for chac node raise 
somehow reserve che device under che hose OS, chen 
pass co the requesting user's executive che 

exclusive reservacion such chac it is recognized by 
Che hose OS. 

o Do we provide generic allocacion, chac is, 

allocacion of any device of a specified cype? If 
3o, whac i3 che bese aechanism? One mechanism, used 
by VAX/VMS, is co allow che user co specify che 
device name withouc Che device number ("L?", for 
example, racher chan ’'LPAO"). Anocher mechod is co 
make device cype a parameter in Che RESERVE command. 

A third approach would be a tvo-scep mechod. 
Assuming device names are in a directory along wich 
an associated "device type" attribute, we can 
suppose a "resource locator" service, which returns 
Co che caller a Use of names chac satisfy a 
specified attribute. The user may chen obtain the 
list and reserve one of che devices named therein 
(assuming ic is still available). This method is 
appropriate if devices can have arbitrary names (see 
"Names" above) (AGRAWALA 83]. 

A problem with the two-step method is that it 
requires evo steps; a device may become unavailable 
between step one and step two. A variation on this 
method is to define a command language function chac 
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returns an identifier of the first available device 
of the specified type; the user nay then, for 
example, "RESERVE fn( 'line printer')" 

o We have provided no mechanism for avoiding deadlocks 
between two or more procedures contending for the 
sane set of resources. For example, procedure PI 
may reserve device Dl, then wait on D2, while P2 has 
reserved D2 and is waiting on Dl. Note, however, 
that the procedures would have to contain explicit 
retry loops (since there is no automatic wait). 

If explicit retry loops are used, we note that a 
remote user is less likely to be able to reserve a 
device than a local user. A requester local to the 
node on which the device is locaced is more apt to 
be successful 3imply because the request can be 
tried more often. In an extrema case, che remote 
user may have to wait on several users that 
requested the device long after the remote user. 
This i3 largely a consequence of our decision to not 
queue the request. 

o Should there be a facility whereby a user or a proc 
is signalled when a device becomes available? 

o If the device is reserved by a user on a node and 
the node crashes is the device automatically 

released? 


In regard to the "device noc available to the network" 
status, there are several reasons a device might be 
available on Che local node, but noc from a remote node: 
The device might require che attendance of che user; 
the device might be a "demand" device, chat 13 , it may 
supply or require data faster chan can be supplied 
across a network link; or che owner of che device may 
simply decide to noc make it available. 

A question to be investigated is whether or not che 
availability of such a device can be accommodated using 
the available protection mechanisms of che NOS. 


7 . Time 

All cimes seen by the NOSCL user are local to che clock 
(if any) on Che specified node. 
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There Is a command co show the current tine on Che local 
node or on any specified remote node. 

Flies have a "cine of creation" attribute; the tine Is 
local co the node on which the file resides. 


Conments 

We have said that co have a single cine base frota the 
user's point of view Is a requirement. 3y this we mean 
that if the user requests the cine from any node— if, 
for example, the user Is logged onto a resote node— the 
cine the user sees will be Independent of the node; in 
addition. If a user U1 creates a file FI on node N, and 
user U2, on a different home node, creates F2 at Che 
sane tine chat FI was created, then both U1 and U2 
should be able co display the file creation tines and 
find thac the file creation cine for FI is the sane as 
the file creation cine for F2 (plus or ninus a few 
seconds) . 

There are difficulties in maintaining a uniform cine 
base across the network: 

Examples of the possible problems are: 

o the clock on one node was never set at boot cine (a 
problem for single-node systems as well); 

o the clock on one node is defective, running at a 
significantly different race than the ocher clocks 
in the net; 

o a node is in a different tine tone chan another 
node; 

o if we cry co sec up a single cine across the system 
using messages, then there will be a special "NOS" 
time, distinct from the respective host tines, a 
phenomenon likely to cause confusion for users and 
system administrators (but one evidently handled by 
computer users who schedule by Greenwich Mean Tine). 

Note chat a useful capability thac depends on a solution 
to the time base problem is the ability co run a proc at 
a specified cine; the common cine base is critical if a 
che initiation of procs in a series must be 

synchronized. 
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Possible approaches to resolving these problems are Co 
be studied; see [LAMPORT 78], [REED 79] for helpful 
prltai elves. 


8. Asynchronous procs 

A user may Invoice a proc, explicitly Indicating that the 
proc is to run "asynchronously", that is, the proc Is 
initiated, and the user is prompted for the next command 
while Che proc is running. 

When an asynchronous proc is invoked, the executive 
prints a message on the user's terminal indicating the 
name of the proc and a SOS-assigned proc identifier; in 
addition, if Che user provides the name of a variable, 
the variable will receive the proc identifier. 

There is a command to wait on a proc with a specified 
identifier, a command to display the status of a proc 
with a specified identifier, and a command to display 
Che status of all active procs. In addition, the A30RT 
command aborts a proc with a specified identifier. 

The WAIT and ABORT commands constitute synchronisation 
commands; an exception handler may be entered only 
following execution of a WAIT or ABORT. 

The following additional rules apply to an asynchronous 
proc: 

o An asynchronous proc survives the termination of the 
invoking proc, but not the termination of the 
invoking session. 

o An asynchronous proc can modify a global variable 
only if the global variable was defined to be 
SHAREABLE (see •'Variables", below). 

o An asynchronous proc cannot declare output 
parameters. 

o Any changes or definitions to logical names, the 
"current" directory, the proc search list, or 
defined command strings have an effect only on the 
asynchronously executing proc and its children; the 
changes do not affect the parent hierarchy. 

o An asynchronous proc cannot reserve a device. 
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Comments 


The ability to execute computations concurrently is 
important for efficient execution of a distributed 
algorithm. Work has been done for several years on the 
most efficient methods for controlling and synchronizing 
concurrent operations. (See, for examples, [LISKOV 79], 
[ICHBIAH 79], [HO ARE 78], [REED 79].) 

The philosophy we have chosen-~-to provide the co mma nd 
language user with the ability to run a proc 
asynchronously and co determine when it is done— 'is the 
current TCL philosophy. We do not provide any 
significant resource synchronization mechanisms, nor any 
inter-proc commnicatlon mechanisms, leaving those 
capabilities to established programming languages. 

Furthermore, we have restricted the operation of 
asynchronous procs such that we do not have to provide 
mechanisms for serializing access to session context 
data. By our proc invocation model, when a remote proc 
is initiated, a spawned executive receives a copy of the 
context data; thus we have our session context data 
replicated, possibly on more chan one node. The 
restrictions we impose seek to serialize access to the 
context data by ensuring that only procs run 
synchronously can change the parent context. 

We do not permit an asynchronous proc co have outpuc 
parameters because output parameters must refer to a 
proc variable, whereas we do not require a parent proc 
to oudive a child asynchronous proc. 


We have declared chat an asynchronous proc dees not 

survive Che death of the parent user session. We 
therefore cannot conveniently support applications such 
as a monitoring system in which a user dispatches 

several asynchronous procs on different nodes and then 

logs out, nor can we provide the user with tne 

capability to initiate a proc on another node, knowing 
that the home node is soon to be taken offline. 

We have taken this approach because it is simple, giving 
a user adequace and safe control. The following topics 
muse be addressed if we allow these "detached" procs: 

- Noting thac a detached proc can run "forever", using 
resources on many nodes, should some sort of 
privilege be required co initiate a detached proc? 
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Should a proc be allowed co Initiate a detached proc 
without explicit user permission? 

How must our proc Invocation model change to 
accommodate detached procs? (If, for example, a 
detached proc wishes to conduce an Interactive 
dialogue, how is it handled?) 

Assuming remote batch Is supported, how many of the 
capabilities provided by detached proc3 are also 
covered by remote batch? 

Should an exception handler in a detached proc be 
executed when the proc that initiated it terminates? 


9. Variables 

"Local" variables are local in scope to the NOSCL 
procedure in which they are declared. Local variables 
may be defined by an interactive user; they are then 
accessible only by that interactive user. 

"Global" variables are accessible from any procedure or 
process (remote or local) invoked within a session of a 
given user, that is, they are defined for the single 
user. The user at the interactive level or any 
synchronous proc (with an appropriate declaration), may 
read or wTite any global variable; an asynchronous proc 
may read any global variable, and may read or write any 
global variable declared SHAREABLE. 

A synchronous proc may also define "outpuc" parameters, 
however, we do not state whether the variables into 
which the output values are placed are set during proc 
execution (call-by-reference) or upon proc termination 
(call-by-value-result) . 


Comment 


This is the current TCL approach, extended by the 
SHAREABLE case. 

We do not provide in the language variables that are 
global to more than one user. Such a facility mighc be 
helpful for inter-procedure semaphores, however, we 
leave inter-proc communication to processes, which have 
available well-known inter-process comainlcatlon 
facilities. 
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The restriction thac asynchronous procs nay have 
read-only access to a global unless it is declared 
SHAREABLE is set to avoid unexpected asynchronous 
effects; thi3 is similar to the single-node case in 
classic programing languages where a user must" place a 
variable in a special place in memory (a designated 
FORTRAN COMMON area, for example) if it is to be shared. 
Note, however, that if shareable variables are provided, 
we nay need to provide a transaction mechanism, because 
we then have the possibility that there is a dependency 
among two or more shareable variables— variable X is 
twice Y, for example. A crash of a remote proc after 
updating one of the variables, but not the other, would 
leave the variables in an inconsistent state. See 
[LAMPSON 81] for more discussion. 


10. User attention sequence and proc aborts 

An attention sequence is defined for each host OS 
(control-C, for example on VAX/VMS). The attention 
sequence solicits the attention of the local executive. 

When the attention sequence is signalled co the 
executive, the executive suspends execution of the 
synchronous proc; the user may then abort a proc, 
suspend a proc, continue, or execute a built-in command 
thac displays status or help information. 

If the attention sequence is used in order co get the 
executive's attention while no synchronous proc is 
running (co break through a terminal read by an 
asynchronous proc), then all executive commands are 
available, including proc initiation. 

If a procedure is aborted, any nest of procs below that 
procedure is aborted as well. 

Responses from a proc may appear at the user's terminal 
after the proc has been apparently aborted. 


Comments 


The synchronous proc is automatically suspended co allow 
the user Co immediately scop an operation out of 
control. Generally, users will run remote procs 
asynchronously; remote procs cannot be automatically 
suspended because the executive doesn't know which proc 
to suspend. Noce chat, when the user enters the 
attention sequence, the user must suffer the 
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communication delay required Co send a "suspend" message 
from Che local exeeuclve Co che reaoce executive of Che 
synchronous proc. 

Messages may be written to che user terminal after 
apparent proc abort because of communication delays in 
sending the abort message to Che remote executive. 

The user is restricted in che domain of operations 
during the interrupt period because of the distributed 
session context problem; it is not clear how the 
context for a synchronous remote proc would be affected 
if che user is able to execute commands Chat change che 
context. 

Some open questions co be studied: 

o If an aborted procedure has initiated asynchronous 
procs, are any procs it has initiated asynchronously 
aborted as well? 

o If we permit remote synchronous procs to run 
additional synchronous remoce procs, doe3 an 

attention sequence result in a cascade of "suspend" 
messages from parent to child? 


LL. Crashes 

If a user has invoked a remoce proc (synchronous or 
asynchronous) and the node on which the proc executes 
crashes, the user is informed thac che proc has failed 
because the node has crashed. The node name is provided 
as well. 

If a node crashes and it has initiated ocher procs, 
those procs will be aborted. 


Comments 


We assume that the communication software in the machine 
thac invoked the proc has the capability co detect the 
crash of a node hosting a proc it has invoked. The 
crash would be signalled to the invcker through che 
normal proc termination mechanism, and the detailed 
status would indicate "crash of remote node...." 
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More analysis is required in regard to crashes. Some of 
Che questions are: 

o Are there any "atomic actions" of concern to the 
command language, that is, are there any command 
level user actions that must be rolled back co a 
synchronization point? (See [LAMPSON 81] and 
[LXSKOV 81] for a discussion on atomic actions.) 

o We have said that procs do not survive a crash of 


Che invoking 

proc's node. The 

reasons 

for 

this 

decision are: 






- Procs are 

intended 

co be 

agents 

of 

an 

interactive user; 

batch 

should 

be 

used 

otherwise 

(see also 

discussion on " 

detached" 


procs, under "Asynchronous Procs," above) 

- If procs are allowed to survive, then a user 
logging in would have to deal with the 
possibility that there are outstanding procs 
that belong co his session. 

- We could provide a session recovery mechanism, 
so that the parent session and proc is restored 
to some synchronization point, but the recovery 

' and re-establishment of the communication co the 
proper point is coo complex co be worthwhile in 
a command language, requiring transaction 
processing mechanisms and delicate timers in the 
surviving procs. (See [LAMPSON 81] for a 
discussion.) 


Assuming that the proc is not aborted, where do 
responses go? Are they saved in a file and sene 
when the crashed node recovers? 

o If the parenc node crashes and the child proc Is 
aborted should an exception handler in the child 
proc be triggered? This would be a useful, cleanup 
mechanism, however, because the exception handler 
could continue as if nothing happened, it implies 
that the NOS muse have a timeout mechanism on the 
exception handler. 

o Is there an efficient way co determine how much a 
crashed remote proc has accomplished? The problem 
i3 that some sort of logging Is required: if Che 

log is on the same node as the remote proc, the user 
cannot make the determination until thac node comes 
up; if the log is on a node remote to the logging 
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node, every command Co be logged would require a 
remote access. A possibility is to make this sort 
of logging optional, thereby making it available for 
long-running procs, or for procs that run on 
unreliable nodes. 

o From [SALTZER 78]: How does the system manager know 

when a node can be brought down without interrupting 
an active remote operation? 


12. Procedures 

The full command language available for procedures on 
single node systems is available on multi-node systems; 
furthermore, all commands are available to the procedure 
regardless of whether the procedure was invoked by a 
user on the same node as the procedure or by a user 
remote to the procedure. 


Comments 


We make this assertion for want of any apparent 
exceptions. 

In addition, we offer the following notes on factors 
affecting procedure portability: 

- Generally, we cannot assume Chat integer overflow 
occurs at Che same value on all nodes on the system. 
Integer overflow at the same value is user-friendly, 
but it is difficult to pick a suitable integer sice 
and inefficient to implement the same sice integer 
on machines with word sices from sixteen bits to 
sixty bits. 

- If Che procedure language provides a floating point 
type, the definition of a floating point number will 
vary from node to node. 

- As noced under "Proc Invocation" above, a proc may 
have been developed assuming a given sec of 
user-defined commands. 

- Inevitably, some procedures and processes will use 
host facilities, generally for efficiency, often 
because the facilities are not made available by che 
NOS. 
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13. Logging/His tory Uses 

NOSCL supports a session history consisting of 
interactive commands to a single log file. Commands 
from procedures are not logged. 

Comment 

TCL currently supports this level of logging; procedure 
commands are not logged because the TCL designers felt 
chat Che log would become too large coo quickly. 

If logging of commands In remote procedures Is to be 
considered, the problem of merging Che logging of 
commands from Che home node with commands from remote 
nodes must be studied. Note that commands from any 
procedure may be logged to Che standard output file, if 
output is redirected appropriately. 


14. Exception handling 

Exception handling follows the model used in TCL: A 
procedure may designate that, upon some "bad" status 
from a proc or command, a procedure-defined "onfail" 
command is executed (typically a GOTO). There is no 
retry capability and no distinct exception signalling. 
See [CENTURY 83a] for a description of the TCL model. 

In addition, we specify that an exception from an 
asynchronous proc is signalled only after a 
synchronization command. See "Asynchronous Procs," 
above. 

Finally, we also define for the NOS a set of standard 
NOS status codes for all known errors. (Thus, a 
procedure exception handler can check for "node down" 
status and perform appropriate recovery.) 

Comment 

We see no problem with this model in regard to working 
in our network environment. 

A problem to be studied is whether or not an exception 
should be triggered upon the crash of a remote node that 
hosts a currently executing proc, or upon the crash of 
any user-specified remote node. Our current position is 
that first case will be handled by normal proc 
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termination handling; the second case is not handled. 
Note chat, for a command language that supports 
exception handlers at the interactive level (TCL does 
noc), a "node crash" exception can be the vehicle for 
printing an appropriate message to the user, or possibly 
doing an automatic reconfiguration. 

See [LANTZ 80] for more discussion on exception handlers 
in distributed systems. 


15. Help facilities 

Help is available on built-in commands, on procs (remote 
and local), on proc parameters, on error response 
details, on the network configuration, and on 
node-dependent capabilities and parameters. 

The help command also has a variation whereby the user 
can obtain help on a built-in command as implemented on 
a specified node. 


Comments 

The help information on built-in commands is made 
available when a new version of the executive is 
released. The user is provided with the ability to 
direct a help request on a built-in command to a 
specific node because tnere au»y be different versions of 
the executive on different nodes. (Recall chat the 
remote executive executes procs submitted to chat node.) 

The help information on node-dependent capabilities is 
made available when the executive is ported to a given 
node. Included in this category are: 

o the computer and operating system installed at this 
node; 

o the version number of the NOS executive installed at 
this node; 

o the values for executive configuration parameters 
(the number of parameters allowed on one line, for 
example); 

o the values for host-dependent parameters (e.g., the 
highest integer allowed); 
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16. Responses 

A standard syntax is defined for responses at the user 
terminal. It consists of: 

<rsp-id> <rsp-text> [ON <aode-id> <hst-text> <herr-code>] 

The <rsp-id> is a unique identifying string for the 
response. There exists a command through which a user 
may determine details on a specified <rsp-id>. 

The <aode-id> is given on all errors that originate on a 
remote node; the <hst-text> is the host-dependent error 
text and is given only if it is necessary in isolating 
the source of the error; the <herr-code> is the 
host-dependent error code, also given only if necessary. 
There exists a command through which a user may 
determine details on a specified <herr-code>. 

On all queries for details on a response, the 
information provided is static; no information is given 
relating to the response in the current context. In 
addition, if a node is given in the error response, then 
the node identification nay be required in the user's 
query for details; the default node is the node that 
last generated an error massage. 

Comments 

The design for response mechanisms is based on existing 
TCL mechanisms. 

The model we have in mind for responses from remote 
nodes is Chat remote executives and procs send responses 
through messages to a virtual terminal process on the 
home node. 

In regard to error information we distinguish these 
classes of errors: 
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1. Errors solely in the NOS domain, "incorrectly 
formatted expression" or "proc cannot be found" are 
examples. 

2. Errors solely in the NOS domain that are caused when 
a user exceeds some executive configuration 
parameter, the number of command line continuations, 
for example. 

3. Errors for which the description can be abstracted 
by the NOSCE, but for which additional host data is 
useful, for example, when a proc cannot be run 
because a host quota is exceeded. 


For the second and third cases, the details on an error 
are node-dependent, thus node-dependent error 
information is included in the error response. 

An alternative to giving the node and host information 
in the Initial error response is to hide the information 
until the user requests it. This approach, consistent 
with the abstract machine approach used by Efe ec al 
[EFE 83], is left for further study. Another 

alternative is to allow the user to specify whether or 
not host error codes are to be displayed. 

Another feature of the response philosophy used by Efe 
is that only the highest level abstract machine 
generates responses to the user. All lower level 

machines field exceptions and abstract those exceptions 
according to their machine specifications. In the 
approach we use above, the executive or proc issues 
responses to the user terminal when the error is 
detected. Thus, while the abstract machine approach 
maintains an internal stack of error information, the 
approach we use puts the same information on the 
terminal. 

We require that the node be specified when the user asks 
for details on errors originating on remote nodes. Thi3 
was done for the following reasons: 

o A mapping for the host-dependent error codes of all 
nodes should not be required at each node. 

o If the error is of the second type described above, 
it Is reasonable to assume that only the node in 
question has the configuration parameters for that 
node. 
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o The details on NOSCL responses — responses common Co 
all nodes~are recained on each node along with the 
executive that generates the responses. This 

assumption is consistent with autonomy: a system 

administrator installs a new release of the 

executive and associated response files when he or 
she sees fit. Note chat there is a natural link 
between a release of the executive and a release of 
the files containing error message details. 


Additional issues 

The following important areas have noc been studied: 

o How are network and machine cost3 modeled for the 
user and how does the command language accommodate 
Che model? (See [ISO/SC16/N1217 82] for initial 

efforts in this area.) 

o What is the context when a user designates host file 
specifications and host commands? What is the 
syntax for host commands to be execuced on remote 
nodes? Should a dialogue with the command language 
interpreter on a remote host be supported? 

Particularly important is the ability for a user to 
bypass the NOS file system, because the NOS file 
3y3tem imposes at least one extra process between 
the file requester and the file and may therefore be 
coo slow for Che user's needs. 

Given the host file escape mechanism, the user 
should have the capability to determine the host 
name for an NOS file, and to determine the hose 
context under which files are accessed (the default 
name string, privileges, and access rights). 

Note that the ability to escape into the host 
command language is often critical in debugging NOS 
functions. 

o Are all NOSCL commands executed synchronously or are 
some asynchronous? For example, is the command that 
writes a record to the standard output synchronous? 
Note that if a procedure on node N2 is initiated 
from node Nl, the standard output is likely to be on 
HI. 



o How are files shared between NOS users and non-NOS 
users? Doe3 the NOS have to lock other users out 
when it is accessing a file? 

o What should be the level of support for remote 
batch, and how does it map into the capabilities of 
host systems? See the SUBMIT commands in COSCL and 
AJSI/X3H1 for guidance. 
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8 .0 SUMMARY 




In this paper our major concern has been how a command 
language changes when used in a local area net of 
heterogeneous computers under autonomous control. 



We have concluded that the user of such a network should be 
exposed to the location of network resources; we identify 
the following key issues thac mu3t be resolved before a 
command language can be implemented: 

o What oust be done so thac the network operating 
system efficiently supports procedures and 
processes executing on a node resioce to the node sc 
which they are invoked? What are che major faccors 
in proc initiation time? . Is the number of 
parameters significant? Must the size of the 
session context be limited? 

o If remote procs can be supported, are the sane 
invocation and prompting mechanisms available as 
for local procs? 

o Are there any restrictions on che commands 
available in remote procedures? 

o Although costing for a distributed environment is a 
complex topic, the user must have some way to 
assess che costs resulting from a session, hew are 
network and machine costs modeled for che user and 
how does the command language accommodate che 
model? 

o Should che network operating system executives, 
which perform command interpretation on each node, 
be parameterized according to the memory and disk 
space available on the hosting node? 

o How much of che protection mechanism must be 
specified in an NOS command language? How do 
protections map into host protection mechanisms? 

o Finally, nocing Thurber's advice (THUR3ER 81] can a 
useful distributed system be built on cop of 
existing hardware and software? 
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APPENDIX A 


CHECKLIST FOR NETWORK COMMAND LANGUAGES 


The following Is a Use of questions to use in examining a 
given network command language. 


o Architecture of the net: 

- Local net or long haul? 

“ Heterogeneous or homogeneous? 

- If homogeneous, what machine/OS constitutes the 
nodes? 

- If heterogeneous, what machines/OS's supported? 

- Gateways supported? 

- Autonomous nodes? 

o Purpose of the net: Is the net used in a 

production environment? A research environment? 

o General description of the command language 

- Did the command language antedate the network? 

If so, was it changed to accomodate the 

network? 

- Any commands that would noc exist if the N/W 
did not exist? 

- Does the command language look the exactly sane 
from any terminal on any node’ 
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CHECKLIST FOR NETWORK COMMAND LANGUAGES 

- Are procedures supported? Are remote 
procedures supported? Any limitations on what 
goe3 in them? (e.g., can a remote procedure 
read from the user's terminal?) 

- Are remote logins supported? 

- Is there a uniform method for logging in to any 
terminal on any node? 


o File system 

- Are names hierarchical or flat? 

- Central or distributed directory? 

- Filespec? 

- Protections? (e.g., capability? access 
lists?) 

- Replicated directory? 

- Can all the resources (i.e., files and devices) 
required by a proc can be secured before the 
proc is run? If so, how? (E.g., user-explicit 
lock) 

- Is remote record access supported? If not, are 
files copied upon proc initiation? 


o Performance: 

- Time to locate and initiate a proc’ 

- Time to copy a null file between two nodes? 

- Time to copy an n-byte text file between two 
nodes assuming no translation? 

- Time to copy an n-byte text file between two 
nodes assuming translation (e.g., EBCDIC to 
ASCII)? 

- Time to copy an n-byte data file assuming data 
type translation’ 
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Interrupts: 

- Is the attention sequence terminal and 
node-independent? 

- How is a remote proc aborted? 

- Can a user run more than one proc at a time? 
If not, can a remote proc be interrupted while 
some built-in commands (e.g-, "show status" or 
"help") are executed? 


How does a user get charged for: 

- Execution of a remote proc 

- Use of a file, directory, or device on a remote 
system (including execution of a remote file 
server) 

- Maintenance of remote files 

- Remote mounting of tapes 


Is there some model of a user getting charged to 
the one user id under which the user logs on (i a., 
the user's id under the network OS)? If so, ho* i3 
this accumulated? 

Privileges: 

- Any notion of privileges in the user view? 

- What kind of privileges does the user have 
under the host? 


Quotas /limits: 

- Any notion of quotas in the user view? 

- What kind of quotas does the user have under 
the host? 


Crash/recovery: 

- Is the user informed of the crash of a remote 
node? 



Tf 


CHECKLIST FOR NETWORK COMMAND LANGUAGES 


- Does the NOS attempt any recovery? 


o Miscellaneous: 


Special security mechanisms (e.g., extra 
passwords/privileges)? 

Any special resource management considerations? 
(T3D) 

Can a user send a message to anyone on the net 
using the same command and addressing as a 
local message? Can the user send a message to 
a system operator? 
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